> Ticket #28 (new defect)
> 
> Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
> 
> Opened 7 months ago
> Reported by: 	kivinen@iki.fi
> Owned by: 	paul.hoffman@vpnc.org
> Component: 	draft-ietf-ipsecme-ikev2bis
> 
> >    o Implementations MUST process received UDP-encapsulated ESP
> >    packets even when no NAT was detected. o The original source and
> >    destination IP address required for the transport mode TCP and
> >    UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the
> >    Traffic Selectors associated with the exchange. In the case of
> >    NAT traversal, the Traffic Selectors MUST contain exactly one IP
> >    address, which is then used as the original IP address. 
> 
> Getting original source and destination IP address from the traffic
> selectors do not really work currently. Especially when combined with
> the selectors from the packet and when responder is behind nat or
> similar problems. 
> 
> Paul: Not done. Specify replacement text and discuss on the mailing list.

I wrote a longer description of the whole transport mode NAT-T
problem, and also added some text which could be used as parts of the
solution to be added to the IKEv2bis.

The problem is that currently there is no way of doing transport mode
NAT-transport without violating at least one of the following MUSTs in
the IKEv2bis document:

ikev2bis-02: section 2.9:

   o  If the responder's policy allows it to accept the first selector
      of TSi and TSr, then the responder MUST narrow the traffic
      selectors to a subset that includes the initiator's first choices.

      and the generic requirement from the same section which in short
      says responder MUST narrow the traffic selectors to be a subset
      of initiators traffic selectors (this is said in quite
      complicated way in IKEv2bis).

ikev2bis-02: section 2.23:
      ... In the case of NAT traversal, the Traffic Selectors
      MUST contain exactly one IP address, which is then used as the
      original IP address.

RFC4301: section 5.2:
...
   IPsec MUST perform the following steps:
...
   4.  Apply AH or ESP processing as specified, using the SAD entry
       selected in step 3a above.  Then match the packet against the
       inbound selectors identified by the SAD entry to verify that the
       received packet is appropriate for the SA via which it was
       received.

The problem with transport mode NAT-traversal and narrowing and SAD
entry checks is that two end nodes talking with transport mode cannot
work if they have same traffic selectors in both ends. This is because
the packet will look like having different IP-addresses depending
which end is seeing it, thus there is no way that both parties could
agree on any single addresses that would work for both ends.

In my following longer text I explain the solution how the transport
mode NAT traversal can be made to work. This will be protocol change,
but on the other hand it cannot break any existing complient
implementations as there was no way to do this before (even when the
RFC claimed so):
----------------------------------------------------------------------
Transport mode NAT Traversal
============================

When transport mode is used with NAT Traversal that requires special
handling of the traffic selectors used in the IKEv2. The complete
scenario is like this:


  +------+        +------+            +------+         +------+
  |Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
  |node  |<------>|  A   |<---------->|  B   |<------->|      |
  +------+        +------+            +------+         +------+

In this scenario there is two address translating NATs NAT A and NAT
B. NAT A is dynamic NAT that maps the clients source address IP1 to
IPN1. NAT B is static NAT configured so that connections coming to
IPN2 address are mapped to the gateways adddress IP2, i.e IPN2
destination address is mapped to IP2. This allows client to connect
server by connecting to the IPN2. NAT B does not necessarely need to
be static NAT, but client needs to know how to connect to the server,
and it can only do that if it somehow knows the outer address of the
NAT B, i.e. the IPN2 address. If NAT B is static NAT, then this can be
configured to the client's configuration. Other options would be find
it using some other protocol (like DNS), but those are outside of
scope of this document.

As other scenarios are just simplications of this complex case (i.e.
where you can just remove NAT A or NAT B), we do not need to consider
them separately.

In this scenario both client and server are configured to use
transport mode for the traffic originating from the client node and
destinationed to the server.

When client starts creating IKEv2 SA and Child SA for sending traffic
to the server, it has triggering packet with source IP address of IP1,
and destination IP address of IPN2. Its PAD and SPD needs to have
configuration matching those addresses (or wildcard entries covering
them). As this is transport mode it uses exactly same addresses as the
Traffic selectors and outer IP address of the IKE packets. For the
transport mode it MUST use exactly one IP address in the TSi and TSr
payloads. It can have multiple traffic selectors if it has for example
multiple port ranges it wants to negotiate, but all TSi entries must
use IP1-IP1 range as IP address, and all TSr entries must have
IPN2-IPN2 range as IP addresses. The first traffic selector of TSi and
TSr SHOULD have very specific traffic selectors including protocol and
port numbers from the packet triggering the request (see section 2.9).

The NAT A will then replace the source address of the IKE packet from
IP1 to IPN2 and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by
the client, but the IP address of the IKE packet has been replaced to
IPN1 and IP2.

When server receives this packet it normally looks the PAD based on
the ID and then searches the SPD based on the traffic selectors. As
IP1 does not really tell anything to the server (it is the address
client has behind the NAT) it is useless to do lookup based on that if
transport mode is used. On the other hand server cannot know whether
transport mode is allowed by his policy before he finds the matching
SPD entry.

In this case it should first check that as initiator requested
transport-mode and do address substitution of the traffic selectors.
It needs to first store the old traffic selector IP addresses to be
used later for the incremental checksum fixup (IP address in the TSi
is stored as real source address and IP address in the TSr is storead
as real destination address for the RFC 3947 use). After that if the
other end was detected to be behind NAT, it replaces the IP-address in
TSi payloads with the IP address obtained from the source address of
the IKE packet received (i.e. in this case replaces IP1 in TSi with
IPN1). If this end was detected to be behind NAT, it replaces the
IP-addresses in the TSr payloads with the IP address obtained from the
destination address of the IKE packet received (i.e. replaces IPN2 in
TSr with IP2).

After this address substitution both the traffic selectors and the IKE
UDP source/destination addresses look same. After this it does SPD
lookup based on those new traffic selectors. If entry is found and it
allows transport mode, then it is used. If entry is found but it does
not allow transport mode, then MUST undo the address substitution and
redo the SPD lookup using the original traffic selectors. If the
second lookup succeeds, it will create SA in tunnel mode using real
traffic selectors sent by the other end.

This address substitution in transport mode is needed so SPD is looked
up by using the addresses that will be seen by the local host. This
also will make sure the SAD entries for the tunnel exit checks and
return packets is added using the addresses as seen by the local
operating system stack.

The most common case is that servers SPD contain wildcard entries
matching any addresses, but this allows also making different SPD
entries for example for different known NATs outer addresses.

After the SPD lookup the server will do traffic selector narrowing
based on the SPD entry it found. In this it will again use the already
substituted traffic selectors, thus it will send back traffic
selectors having IPN1 and IP2 as their IP addresses (it can still
narrow down the protocol number or port ranges used by the traffic
selectors).

The SAD entry created for the Child SA will have the addresses as seen
by the server, i.e. IPN1 and IP2.

When the initiator (client) receives the other ends reply to Child SA
it will do similar processing. I.e. if transport mode SA was created,
it will store the original returned traffic selectors as real source
and destination addresses for the RFC 3947 use. Then it will replace
the IP addresses in the traffic selectors with the ones from the IP
header of the IKE packet, i.e. it will replace IPN1 with IP1 and IP2
with IPN2. Then it will use those traffic selectors when verifying the
SA against sent traffic selectors, and when installing the SAD entry.

Specific rules for to be followed for transport mode:

Initiator proposing transport mode:

	- The TSi entries MUST have exactly one IP address, and that
	  MUST match the source address of the IKE SA .

	- The TSr entries MUST have exactly one IP address, and that
          MUST match the destination address of the IKE SA.

	- The first TSi and TSr traffic selectors should SHOULD have
	  very specific traffic selectors including protocol and port
	  numbers from the packet triggering the request (see section
	  2.9).

	- There MAY be multiple TSi and TSr entries.

	- If transport mode for the SA was selected (i.e. responder
          included USE_TRANSPORT_MODE notification in its reply):

	     - Store original content of traffic selectors as real
               source and destination address for the RFC 3947 needs.

	     - If other end is behind NAT substitute the IP address in
               the TSr entries with the remote address of the IKE
               SA.

	     - If this end is behind NAT substitute the IP address in
               the TSi entries with the local address of the IKE SA.

	     - Do address substitution before using those traffic
               selectors for anything else than storing original
               content of them. This includes verification that
               traffic selectors were narrowed correctly by other end,
               creation of the SAD entry etc.

Responder when transport mode is proposed by initiator:

	- Store the original traffic selector IP addresses as real
          source and destination address for the RFC 3947 needs, and
          for in case we need to undo address substitution.

	- If other end is behind NAT substitute the IP address in the
          TSi entries with the remote address of the IKE SA.

	- If this end is behind NAT substitute the IP address in the
          TSr entries with the local address of the IKE SA. 

	- Do PAD and SPD lookup using the ID and substituted traffic
          selectors.

	- If no SPD entry was found, or if found SPD entry didn't
          allow transport mode do following:

	     - Undo the traffic selector substitutions.

	     - Do PAD and SPD lookup again using the ID and original
               traffic selectors, but also searching for tunnel mode
               SPD entry (i.e. fall back to tunnel mode). 

	- If transport mode SPD entry was found:

	     - Do normal traffic selection narrowing based on the
               substituted traffic selectors and SPD entry. Use the
               resulting traffic selectors when creating SAD entries,
               and when sending traffic selectors back to the
               initiator.
-- 
kivinen@iki.fi